-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[clr-interp] Async Resume stubs are exclusive to the JIT as they use a set of intrinsics that are JIT specific #123046
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[clr-interp] Async Resume stubs are exclusive to the JIT as they use a set of intrinsics that are JIT specific #123046
Conversation
…a set of intrinsics that are JIT specific - Disable running the interpreter compiler for these. In real scenarios we will either have a JIT to generate them, or they will be produced by the R2R compiler, so this should be a good long term solution
|
Tagging subscribers to this area: @BrzVlad, @janvorli, @kg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR prevents the interpreter from attempting to compile async resume stubs, which use JIT-specific intrinsics that the interpreter cannot handle. The fix ensures that these stubs will be generated either by the JIT or R2R compiler.
- Adds a new
IsAsyncResumeStub()method to check if a dynamic method is an async resume stub - Updates the interpreter loading condition to skip async resume stubs
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/coreclr/vm/method.hpp | Adds IsAsyncResumeStub() helper method to DynamicMethodDesc class, following the same pattern as other stub type checking methods |
| src/coreclr/vm/jitinterface.cpp | Modifies interpreter loading condition in UnsafeJitFunction to exclude async resume stubs from interpreter compilation |
Co-authored-by: Copilot <[email protected]>
The change is now materially different
janvorli
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
- Disable running the interpreter compiler for these. In real scenarios we will either have a JIT to generate them, or they will be produced by the R2R compiler, so this should be a good long term solutionImplement the second half of the intrinsic for SetNextCallAsyncContinuation. This allows the interpreter to correctly generate code for async resumption stubs (although it won't use them itself, as the interpreter has a different path for calling async resume stubs that we don't currently plan to remove. This is used in some of our interpreter test modes where the runtime may choose to JIT a runtime async method and interpret its associated async resumption stub.